home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15974 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.7 KB  |  85 lines

  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: Re: Simple elastic list in C++...
  5. Message-ID: <marnoldDpJ98F.3q5@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <4ka4d5$cia@park.interport.net>
  8. Date: Mon, 8 Apr 1996 07:38:39 GMT
  9. Sender: marnold@netcom12.netcom.com
  10.  
  11. scamhi@interport.net (Steven Camhi) writes:
  12.  
  13. >As a programmer old to C, new to C++, I have seen no 'simple' answer to the 
  14. >following situation.   In most cases, the easiest, simplest way (for me, that 
  15. >is), to create a growable list in straight ANSI C, has been the following:
  16. [snip]
  17. >What is *the best* way of doing dynamically growable lists in C++, without a 
  18. >headache?  
  19.  
  20. Uh, use STL?
  21.  
  22. >Perhaps there is no *best* way, what is the way to approach the 
  23. >problem of manufacturing a simple list class.  One way I have seen is the use 
  24. >of the STL vector classes; thats been my frame of reference.  
  25.  
  26. There's not many ways to do it other than the how the vector class in STL
  27. is implemented.  That's the basic model when the base implementation is an 
  28. array (contiguous items in memory).  You resize the block holding the array, 
  29. move items up and down, etc..
  30.  
  31. The next technique would be linked list.  Again, not to many variations 
  32. there.  The STL implementation (the list class) is as good as any other.  
  33. The only real choice is whether you use a singly- or doubly-linked list.  
  34. STL uses a doubly-linked list, I believe.
  35.  
  36. >I've seen some examples on the net use realloc(), and I've heard thats a major 
  37. >no-no!  Whats the right way?
  38.  
  39. Mixing C++ new/delete with realloc() is the no-no.  Using reallac() itself
  40. is OK---although it's only meant to be used with memory returned by malloc(), 
  41. of course.  realloc() and malloc() are part of the standard C library.  All 
  42. C++ programs are C programs---there's nothing stopping you from using the 
  43. standard C memory allocation routines in a C++ program if you want to.  Just 
  44. #include "alloc.h" and code away.  You just have to be careful not to use 
  45. operator::delete() on memory you got from malloc(), etc..
  46.  
  47. This is an example of the "no-no's" you've heard of...
  48.  
  49.    Object* p = new Object();
  50.    realloc(p);   // no, NO!
  51.  
  52. There's no garantee that new() and realloc() use the same underlying
  53. memory manager.  Passing realloc() an address obtained from malloc()
  54. is just like passing it garbage.  You're likely to corrupt new's heap,
  55. the C library's heap, or both.
  56.  
  57. This is fine...
  58.  
  59.    MY_DATA* p = (MY_DATA*)malloc(sizeof(MY_DATA));
  60.    p = (MY_DATA*)realloc(p, sizeof(MY_DATA) + 42); 
  61.  
  62.  
  63. Question:  If you need lists, what's wrong with using STL?  Taking care of 
  64. these kinds of programming issues in a standardized way is what something 
  65. like STL is all about.  Why not use it?
  66.  
  67. 'Course, I have found that trying to create container classes in C++ to
  68. be a very good learning experience.  I encourage you to persue that if 
  69. this is what you are after.  However, for the people who created STL at
  70. HP, this was their *job*, or at least a very important "extra-curricular" 
  71. activity.  They've done a very good job with it, I think. 
  72.  
  73. For learning STL, I've found the book "The C++ Programmer's Guide to the
  74. Standard Template Library" from IDG books to be quite good.  It comes 
  75. with the HP version of STL. 
  76.  
  77. Regards,
  78. -------------------------------------------------------------------------
  79. Matt Arnold                       |        | ||| | |||| |  | | || ||
  80. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  81. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  82. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  83. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  84. -------------------------------------------------------------------------
  85.